Related Plugins and Tags

QGIS Planet

Introducing the new QGIS.org website

We have a new website!

We recently launched our new website at QGIS.org. It is a ground-up overhaul and provides a fresh take on the first contact point for existing or potential users wishing to engage with the QGIS project and discover its value proposition.

A new strategy for QGIS.org websites

In this blog post, we would like to provide an overview of the goals that we had for building the new QGIS.org website and the bigger picture of how this website update fits into the broader strategy for our website plans for QGIS.

About two years ago, we started experimenting with building a new QGIS.org website based on Hugo. Hugo, as a technology choice, was less important than was our intent to develop a more modern site that addressed our strategic goals.

After some ‘in-house’ (i.e. volunteer-based) work to develop an initial version of the site, we received the go-ahead to use QGIS funds for this and put out a call in October 2023 for a company to support our work. This was ultimately won by Kontur.io, who, together with our volunteers, brought the work into high gear.

Questions to be quickly answered by qgis.org
Initial analysis of the questions and actions to be quickly answered by qgis.org

Goal 1: Speak to a new audience

Our primary goal was to speak to a new audience. We are confident that QGIS can compete with all of the commercial vendors providing GIS software. We didn’t convey that well on our old website. We feel that QGIS was too apologetic in how it presented itself. We wanted a website which inspires confidence while addressing the needs of a corporate or organisational decision-maker who is looking at the QGIS project during their GIS software selection process.

The old website was very focused on the developer and contributor community. Obviously, those aspects are important since, without our fantastic community, the QGIS project would not exist. The messaging around open source is also important. Yet these ideas are secondary to the idea that QGIS is one of the best (if not the best) desktop GIS applications out there on the market – open-source or otherwise. We need to present it in this professional perspective.

So, the first goal was to change the messaging to focus on QGIS’s value proposition and take a very professional approach to presenting ourselves on the website.

User group analysis
User group and requirements analysis for the potential qgis.org visitors

Goal 2: Harmonisation

The second goal was to start the process of harmonising all of our website properties. QGIS.org, over the years, has built many different web properties. For example, there’s the plugins website, the feed, the changelog, the sustaining members website, the lessons website and the certification website, the new resources hub website, the API documentation, the user documentation, the user manual, the training manual, various other documentation efforts, and more. Some of those are combined in one application, There are also some less well-known resources, like our analytics.qgis.org and another one for plugin analytics. In short, we’ve a lot of resources!

With so many different web properties, they’ve devolved over time: each has its own look and feel, navigation approach and how you interact with it. Some of them were translated, and some of them were not. We want to harmonise all of these sites so that the user does not notice any change in user experience when they move from one QGIS-related site to another.

Goal 3: Harmonising deployment

In the underlying process of these changes, we’re also redeploying all of the websites on new servers, which are more up-to-date and use better security and maintenance practices. Plenty of work is happening in the background to ensure that all of the servers are in a better-maintained state, document how they’re maintained, and so on.

Goal 4: A hub and spokes

The objective of the new site design is to allow quick movement between the QGIS auxiliary sites. The QGIS.org site will form a hub that effortlessly takes visitors to whichever QGIS-related site they need to complete the task they are busy with. If you’re moving between these sites, the experience should be seamless. You should not really even be aware that you’re moving between different websites. Other than looking at the URL bar, the user presentation and experience should be harmonious between all of them.

One way we are planning to achieve this is to have a universal menu bar and footer. You will see that in the new website’s design, there is a menu bar across the top. This menu bar has two levels: the top menu and the second level, where the search bar is.

The universal menu bar

In this second row, auxiliary sites will have their own sub-menu whilst keeping the shared top-level menu. So if you, for example, are moving around in plugins and want to review the plugin list or submit a new plugin, all of that navigation will be on the second line where the search bar is currently. Regardless of which subdomain you are on, the top-level menu bar will be the same, allowing you to easily navigate back to the hub or to another subdomain.

The footer will be unified and shared between all sites, and the cascading style sheets and styling will be unified across all of the QGIS websites.

In the next phase, we will work to achieve this coherence across all the websites, though we still have a few more tweaks to make to the qgis.org site first.

Goal 5: DOTDOTW – do one thing, do one thing well

We plan to break some auxiliary websites apart into separate pieces. So, for example, the changelog management, certification management, sustaining members management, and lessons management are all in one Django app. We will split them into small single-purpose applications using some common UX metaphors so that each is a standalone application that makes it easy for a potential contributor to understand everything the application does. This will also simplify management as we can upgrade each auxiliary site on separate development cycles. We will also finally have semantic URLs, e.g. certification.qgis.org, to take you to the different areas of interest on the site.

The plugins.qgis.org is also going to be refactored so that it just has plugins and not the resource sharing we’ve added in the last few years. The resource sharing will go into its own subdomain. Similarly, the Planet website will get split into its own website (the planet is a blog aggregator or RSS aggregator) that will be in its own managed instance. Some other components (like the analytics) are difficult to split out like this because they’re linked to the same database. We will try to make sure that those are more discoverable and theme them as much as possible to match the rest of the website experience.

Goal 7: Encapsulation

Another goal we had for the QGIS.org makeover was to make the site performant and self-contained. By self-contained, we mean that it should not ‘call’ out to CDN, Google or other platforms for resources like fonts, CSS frameworks, javascript libraries, etc. There were two reasons for this:

  1. These platforms often use such resources to track users as they move around the Internet, which we want to avoid as much as possible.
  2. We want to wholly manage our site, be able to fix any issues independently and generally follow a path of self-determination.

Our approach also facilitated the creation of a very performant website, as you can see here. We will try to adhere to these principles for the auxiliary site updates we do in the future, too.

What about translations?

The question has come up: Why did we not want to translate the new QGIS.org when it was translated before?

Firstly, we should make it clear that we do not plan to remove translations from the user documentation, the user manual, and so on, where we think they have the most value.

For the main QGIS.org site, we question whether there is a high value in translating it. Here are some reasons why:

1. Lingua franca: If you are an IT manager in a non-English-speaking country and you want to evaluate some software, you’re going to run into a product page that presents itself in English – it is the norm for IT procurement to work in English for reviewing software products and so on.

2. Automation: Automated translations inside browsers are getting better and better. While these translations are still not completely adequate, we think they will be in one or two years’ time.

3. Translation integrity: Our pursuit of Goal 1 means that we would no longer find it acceptable to have partial website translations. We also need to ensure that the wording and phrasing are consistent with the English messaging. We also have concerns about the QA process regarding trust and review – we want to ensure that any translation truly reflects the meaning and intent of the original content and has not been adjusted during the translation process.

4. Cohesion: Our most important point is raised if we go back to this idea of cohesion between the different websites like QGIS.org, plugins.qgis.org and so on. As well as having the same styling, we also don’t want to switch between languages as you hop between the sites. We aim to present them all as one site. If we translate QGIS.org and then take you to our auxiliary sites, e.g., plugins.qgis.org, the feed, or certification pages, which are in English only, the experience is jarring.

So we must either translate everything into all of the same languages, or work in English. Translating everything is a mammoth task for the translators and for us to retrospectively add translation support to each platform. Thus, we prefer the approach of harmonising everything to one language and then focusing our translation efforts on three areas:

  1. The application itself,
  2. the user manual and
  3. the training manuals.

We can leave the rest of the experience in English and instead focus on harmonising, for now, both in terms of look and feel and the technology used.

When we consider everything as one big website and what the bigger plan is, it is hopefully clearer why we didn’t think translating the landing page and QGIS.org was the best approach.

Further funded work

We hope to use more QGIS funding to support this work in the future. We’re also hoping to work again with Kontur to start moving all these auxiliary sites into their own projects, applying our style guidelines to each. Independently of that, Tim (volunteer), Lova (QGIS funded), and others are already getting started with this process.

Helping out

Do you have strong opinions about the website? Contact Tim on the PSC mailing list if you would like to get involved as a volunteer. We would love to hear from designers, word smiths, marketers, information architects, SEO specialists, web developers and those who think they can help us achieve our goals.

Conclusion

We hope our goals and process make sense for everybody and that we were able to lay out a clear, logical argument about why we don’t want to translate the new website quite yet. We want to focus on these overarching goals and then return to them later if they are still a priority for people. Everything we have built is Open Source and available at this repo, where you can also find an issue tracker to report issues and share ideas relating to the new website.

Thanks for reading. Go spatial without compromise 🚀🗺

Cheers, Tim, Marco and Anita

QGIS Userbase Analytics

Background

Understanding which regions QGIS is being used in, which versions are in active use, which platforms it is being used on, and how many users we have is hugely beneficial to our ability as a project to serve our users. Back in 2017 at the bi-annual QGIS hackfest in Nødebo, Denmark, we had a long discussion about key project goals and the need to better understand our user base in order to plan the future direction of the project, and allocate funding and resources to where they are needed most

Typically proprietary software vendors have ready access to detailed user data through telemetry code which they embed in their software. This telemetry code ‘phones home’ key metrics, which together with other techniques such as license sales analysis gives them a very detailed insight into their user base. The data these vendors collect is typically not shared, so their users do not benefit from being able to understand how their data is used.

For QGIS.org, having to resort to what are generally considered to be nefarious and privacy-invading techniques of siphoning user data from our users goes against the ethos we try to promote as an open project. Further, since QGIS is freely available and doesn’t require any self-registration, we do not have a user database we can consult for such analytics. Additional factors make understanding usage levels hard. For example, a single user can download a copy of a QGIS installer and distribute it to many other users, and conversely web crawlers and bots can download many copies of QGIS installers and never install them. Because of this, simply counting the number of downloads from our website does not give a useful picture of our user base.

So we needed to come up with an approach that:

  1. Does not invade our user’s privacy
  2. Does not require including telemetry code in QGIS which exfiltrates user information from their system
  3. Does not store any user-identifiable data on our servers
  4. Is open and transparent in the data collection methodology
  5. Openly shares the insights we gain from our analytics to the broader community

The most obvious privacy-respecting way we could find to understand more about our users was to collect metrics of access to the QGIS News Feed. In order to display the latest news on startup, QGIS Desktop makes a request to https://feed.qgis.org when it is opened. On the server that hosts the feed, we can then use the web server logs to understand which operating system and version of QGIS made the news feed request. Additionally, using the GeoIP library we can resolve each request to the country from which it originated. These pieces of information are included in the User-Agent headers sent by QGIS when it makes a request to the QGIS News Feed.

This process is anonymous, transparent, and simple to disable. It does not identify unique machines. Only one event is logged per unique network per hour. Only one event is logged per QGIS installation per day, and the event is only triggered when the user opens the QGIS Desktop application.

Operating system statistics are derived from QGIS version information, and no system fingerprinting or telemetry is implemented.

Location information is derived from the request source IP address, which is immediately discarded on the server after resolving it to the country of origin.

No logging on the QGIS News Feed server occurs with legacy installations that do not have the news feed feature, offline usage of QGIS, and installations for which feed collection is disabled (see below for info on how to disable it). It will also have statistics skewed in scenarios where atypical networking infrastructure is in effect, such as using a virtual private network.

Despite these caveats, the statistics should provide a good high-level overview of how QGIS is being used, such as the breakdown of QGIS across operating systems and versions – information that is incredibly useful to the QGIS developer team. Only the following four pieces of information are collected:

  • The date (aggregated by day)
  • The QGIS version
  • The Operating System
  • Country (based on IP which is immediately discarded)

Opting out

If you wish to opt-out of this data collection, simply disabling the feed retrieval, using QGIS offline, or blocking access to the QGIS RSS feed address (feed.qgis.org) on your network will exclude you from this process. QGIS Desktop provides options for disabling version checking and feed access under Settings ➔ Options ➔ General ➔ Application. Note that by default this setting is specific to each individual user profile.

Viewing the analytics

We have made a public dashboard publicly available at https://analytics.qgis.org. The dashboard was made using the fantastic open-source Metabase analytics package.

Credits: This post was written by Charles Dixon-Paver and Tim Sutton

QGIS LTR 3.16.13 reverted to 3.16.11

Dear community,

Due to some rather severe issues in the 3.16.13 and .12 Windows MSI installers, we decided to temporarily revert back the available download to the latest release without those issues, 3.16.11. The website rebuild has been performed and you’ll see everywhere that 3.16.11 is the latest LTR. This is true for Windows only as other OS will keep delivering the latest 3.16.13.

Next Friday 19th November is the planned release date for 3.16.14 which should bring fixes to both the above mentioned issues and restore the normal release flow.

Quoting our release manager Jürgen Fischer:”Only the 3.16.13 MSI is broken (not sure if 3.16.12-2 is affected). OSGeo4W
v2 was meanwhile fixed. All other platforms are not affected at all. The next release is on Friday and will also produce a fresh MSI.”

We apologize for the inconvenience and would like to take the opportunity to remind you how much work goes into producing and maintaining the high quality product that you’ve grown to love and that this is only possible thanks to our sustaining members and volunteers. If you or your organisation is relying on QGIS, it might be a good time to consider joining QGIS’ funding effort at https://qgis.org/funding or https://github.com/sponsors/qgis/

Have a great week, cheers

Marco

Original post: https://lists.osgeo.org/pipermail/qgis-user/2021-November/050193.html


Megaphone icon made by BomSymbols from www.flaticon.com

  • Page 1 of 1 ( 3 posts )
  • public service announcement

Back to Top

Sustaining Members